This forum is closed to new posts and
responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:
First of all, the limit you claim of a 255-character max for Evaluate doesn't exist and hasn't since R5.
You're right. It's still a bit fuzzy, but I think I was recollecting an issue with @Eval, and the limit was likely imposed by additional formula that was selecting the formulas to run from configuration documents. Still trying to recall the exact details. As you might have guessed by my attitude, it's been a very, very long time since I've coded a large process using formula. :P
1. Terseness - @Middleback(), @SetField(), @DbLookup(), etc. are much easier to read as small snippets in @Formula than their equivalents in LS, Java, or SSJS.
Oh come on...they're not THAT much smaller.
2. @DbColumn - it's slower and much more spammerific to use NVN than an @DbColumn. NVN will give you category totals and could theoretically handle more rows, though.
I did some test on a view with 2500 docs, representing just over 35k of data to be retrieved. @DbColumn is fast both locally and on a server. LotusScript was nearly as fast locally (nearly one second) but needed about 10 seconds when the code was accessing a server. So it's not LotusScript per se, but the fact that it has to access each view entry individually from the server that makes it slow, as oppose to @DbColumn, which, I'm guessing, has a server component to it so that it can make only one request to the server.
In any case, for UI functions I'd just use picklist and not worry about the 64K limit, or a paging system and show users 25 items at a time. That usually responds instantly to the users. It's too bad that IBM abandoned LotusScript. I'm sure we would have a column function by now if they hadn't.
3. Context - There's an @Formula version of Evaluate, @Eval. This means that <computed text> blocks, field defaults, etc. are trivial to implement via @Formulas.
I guess. I stopped using default, translation, and validation formulas a long time ago. I don't use Pages much, but that's just me.
4. Agents - A simple @Formula agent is almost always faster than its simple LS/Java equivalent.
Probably right. But you still can't debug it. When formula doesn't work, it's always a guessing game as to what's wrong. And I've seen people spend a very long time guessing at problems.
5. Garbage Collection - I just threw this in because @Formulas have much better garbage collection than N/D's implementation of Java (kind of sad if you think about it). This doesn't really apply to LS though.
Probably because formula can't create any variable more complex than an array of dates. Who knows how messy things might get if formula could work with objects. Should we petition IBM for object-oriented formula?
Feedback response number WLOO7YT5H5 created by ~Julia Feztoosterader on 12/17/2009
re: Ok, I'll bite.
Return to top
. . . . . . . . . . re: Ok, I'll bite. (~Fred Xanjumima... 17.Dec.09) 
